Summary

This PR adds an upstream wolfBoot port for the AMD/Xilinx Zynq-7000 SoC (Cortex-A9, ARMv7-A), verified end-to-end on the ZC702 Evaluation Kit. The port covers QSPI cold-boot, SD-card cold-boot, JTAG-loaded development, and signed Linux / U-Boot / bare-metal payload chain-loading from a single TARGET=zynq7000 build target.

It also generalises the existing ARMv7-A startup file so SAMA5D3 (Cortex-A5) and Zynq-7000 (Cortex-A9) now share one path through src/boot_arm32_start.S and src/boot_arm32.c.

A late simplification removes the LINUX_PAYLOAD=1 config knob that earlier revisions of this PR required, and hardens the legacy U-Boot uImage header detection with a CRC32 check. The result is a single config that "just works" for both bare-metal and Linux payloads, with no per-deployment switch.

What's in the port

New files

• hal/zynq7000.c, hal/zynq7000.h, hal/zynq7000.ld -- HAL: UART, GPTimer, QSPI (XQspiPs N25Q128), Arasan v2.0 SDHCI hooks, cache teardown.
• config/examples/zynq7000.config -- QSPI deployment (BootROM -> FSBL -> wolfBoot -> kernel/app).
• config/examples/zynq7000_sdcard.config -- SD-card deployment with MBR layout that the Zynq-7000 BootROM accepts (FAT32-LBA + Active flag in p1).
• test-app/app_zynq7000.c, test-app/ARM-zynq7000.ld -- bare-metal banner + heartbeat for end-to-end verification.
• tools/scripts/zynq7000/* -- prepare_linux.sh, prepare_sdcard.sh, jtag_load.tcl, zynq7000_qspi.bif.
• docs/Targets.md -- ZC702 bring-up walkthrough, QSPI / SD / JTAG paths, Linux recipe, ZynqMP comparison.

Touched

• src/boot_arm32.c -- always emits the ARM Linux boot ABI when MMU=1 (r0=0, r1=~0, r2=DTB, r3=0). Bare-metal payloads ignore r0..r3, so one ABI covers both payload types. No more per-target LINUX_PAYLOAD switch needed.
• src/boot_arm32_start.S -- generalised ARMv7-A startup (VBAR, per-mode stacks, cache invalidate, async-abort enable). Replaces what was a Cortex-A5-specific file; SAMA5D3 now uses the same path.
• src/update_ram.c -- legacy U-Boot uImage header detection now validates magic + header CRC32 + payload size, dropping the joint false-positive probability from ~2^-32 to ~2^-64 and matching U-Boot's own mkimage/bootm validation. Reuses gpt_crc32_* from src/gpt.c.
• arch.mk -- new CORTEX_A9=1 block under TARGET=zynq7000. WOLFBOOT_UBOOT_LEGACY is now always-on for zynq7000 (matching sibling ZynqMP / Versal targets); the previous LINUX_PAYLOAD=1 gate is gone. src/gpt.o is now linked for every Cortex-A9 build and every AARCH64 RAM-update build (where the hardened uImage check uses it).

Three boot paths, one config flavour

The QSPI config is the primary path. MMU=1 ELF=1 are baked in by default so the same wolfBoot image can chain-load a signed bare-metal .bin, a signed U-Boot, or a signed Linux zImage. Bare-metal payloads ignore the ARM Linux ABI registers wolfBoot passes in. Cost vs. a strictly bare-metal build is about 5 KB of unused FDT/MMU code (31 KB -> 36 KB).

For SD-card boot the layout is pure MBR (FAT32-LBA + Active in p1 for BOOT.BIN; raw Linux partitions p2/p3 for signed BOOT_A / BOOT_B). The BootROM (UG821 ch.6.3) refuses the GPT layout used on ZynqMP / Versal. src/disk.c's MBR-fallback handles this.

For Linux from SD we default to CONFIG_ARM_APPENDED_DTB (DTB concatenated to zImage and signed as one image), since the ARMv7 zImage decompressor on this kernel/load combo does not always preserve r2 across the transition to decompressed head.S. The raw-DTB-from-partition path via PART_DTS_BOOT remains plumbed for kernels that handle r2 correctly.

Booting Linux through wolfBoot

Verified end-to-end with stock Xilinx Linux 6.1.70 (xilinx_zynq_defconfig) and zynq-zc702.dtb. wolfBoot reads the signed kernel out of QSPI / SD, verifies it, copies it to DDR at 0x10000000, disables MMU and caches, and bx's into the zImage decompressor. Linux brings up both Cortex-A9 cores, the L2C-310, and the full SMP init; it panics only when no rootfs is supplied (expected for the proof-of-concept).

Hardened legacy uImage detection

The wolfBoot legacy uImage strip (WOLFBOOT_UBOOT_LEGACY in src/update_ram.c) previously matched on magic only -- one 32-bit comparison against UBOOT_IMG_HDR_MAGIC. That left a ~1-in-2^32 false-positive window for non-uImage payloads whose first 4 bytes happened to collide with the magic.

This PR replaces the magic-only check with a structural validator that requires all of:

• ih_magic == 0x27051956
• ih_size (big-endian) is > 0 and fits inside the signed image (<= total - 64)
• ih_hcrc matches the CRC32 of the 64-byte header with the hcrc field treated as zero -- same algorithm (reflected CRC-32, poly 0xEDB88320) and same field semantics that U-Boot's mkimage / bootm use

Joint collision probability drops from ~2^-32 to ~2^-64. The CRC32 implementation is the existing gpt_crc32_* helpers in src/gpt.c, so no new code is added beyond the validator itself.

The hardening covers all targets that enable WOLFBOOT_UBOOT_LEGACY: zynq7000 (this PR), ZynqMP, and Versal.

Build verification

All four affected configurations build cleanly with no warnings or errors:

The SAMA5D3 regression confirms the non-MMU branch of the generalised do_boot (used by targets without MMU=1) is unaffected by the always-Linux-ABI change.

Known limitations / follow-ups

• ARMv7 zImage r2 quirk -- the appended-DTB path is the documented default. The raw-DTB-from-partition path works for decompressors that preserve r2; needs upstream Linux investigation before we can recommend it generally.
• SDHCI v2.0 6 MHz cap -- src/sdhci.c needs an explicit DAT-line reset between transfers before we can raise the post-init clock. Sufficient for boot-time loading today (~3 MB/s).
• L2 (PL310) -- not touched by wolfBoot; stock ZC702 FSBLs don't enable it. If a custom FSBL does, extend hal_prepare_boot() with an L2x0 clean-invalidate + disable.

Why a separate port from ZynqMP?

Despite the shared name, the two SoCs differ in nearly every block wolfBoot interacts with:

With this PR the entire AMD/Xilinx adaptive-SoC lineup -- Zynq-7000, ZynqMP, Versal -- builds from a common wolfBoot codebase.